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REMARKS 

The Office Action dated November 30, 2005 (the "Office Action") rejected all pending 
claims in this application, which included claims 1-29 and originally presented independent 
claims 1 and 16. Following entry of the present Response and Amendment, claims 1-4, 7-8, 10- 
19, 22-26 and 28-29 still remain pending in this application. 

With regard to prior art, the Office Action rejected claims 1-29 under 35 U.S.C. § 103(a) 
for allegedly being unpatenable over U.S. Patent No. 6,418,467 to Schweitzer et al. (henceforth, 
"Schweitzer") as modified in view of U.S. Patent No. 6,832,250 to Coons et al. (henceforth, 
"Coons"). 

In the present Response and Amendment, portions of the written specification have been 
amended to correct typographical errors. No new matter has been introduced by these 
amendments to the specification. 

Rejections under 35 U.S.C. $ 103(a) 

The Office Action rejected all claims under section 103(a) based upon Schweitzer as 
modified in light of Coons. Insofar as this rejection applies to the present claims, Applicant 
traverses as follows. 

As described in detail in Applicant's prior paper, independent claims 1 and 16 recite 
subject matter that is both novel and non-obvious with respect to Schweitzer. Further, Applicant 
submits that such subject matter is also non-obvious over Schweitzer to the extent that that 
reference can be properly modified in light of the teachings of Coons. 

As noted previously, claim 1 recites a computer implemented method for combining 
usage data from a plurality of network elements, which includes the steps of collecting usage 
event data records from a plurality of network elements, associating with each event data record a 
key module identifying usage event data as pertaining to a particular usage session, converting 
that usage event data records into a normalized format, and aggregating said normalized usage 
event data records. The usage detail records are then exchanged with downstream elements by 
converting the usage detail records into an appropriate data output format and distributing them 
to the downstream elements. As the Applicant has previously emphasized, claim 1 further recites 
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that the aggregating of the normalized data records is accomplished by associating records for 
related events with one another according to the key modules to form usage detail records. Each 
of these usage detail record include the imique key module plus usage data of a known length for 
one or more usage event data records pertaining to a same usage session (i.e., the usage session 
identified by the key module in the previous associating step). Claim 1 additionally recites that 
the aggregating step employs an in-memory database comprising a hashing table and page files 
retained in local memory where the page files and hashing table are related according to the key 
modules for the records, and the normalized and aggregated usage event data records are located 
in said page files. 

Similarly, claim 16 further recites a multi-tiered computing architecture containing a 
front-end component, a core mediation component, and a back end component. The fi-ont-end 
component is adapted to collect usage event data records from a plurality of network elements 
and convert these usage event data records into a normalized format. Like claim 1, claim 16 
recites that the normalized usage event data records have a key module that identifies usage event 
data as pertaining to a particular usage session. The core mediation component as claimed is 
adapted to aggregate normalized usage event data records according to their key modules into 
usage detail records by associating said normalized records for events related to a same usage 
session. Each usage detail record includes the key module and including usage data of a known 
length for one or more usage event data records pertaining to a same usage session. Again, like 
claim 1, it is recited that the aggregating step is performed using an in-memory database having a 
hashing table and page files retained in local memory, with the page files and hashing table being 
related according to said key modules, and the normalized and aggregated usage event data 
records being located in the page files. 

As noted previously, since the data records are hashed and aggregated according to their 
key modules, a second level of efficiency is obtained above and beyond the use of hashing tables 
and databases stored in dynamic memory. Thus, the present invention is particularly 
advantageous over prior systems when used to monitor and aggregate billing records fi'om large 
network systems. 

As recognized by the present Office Action, Schweitzer fails to not only disclose the use 
of hashing tables and in-memory databases as defined in the claims, but also fails to disclose how 
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the key module not only identifies records for events firom the same session, but also is used to 
relate the hashing table to the information of the usage detail records in the page files. A fiill and 
proper reading of Schweitzer makes clear that Schweitzer provides no teaching that would 
motivate one skilled in the art to produce Applicant's invention as presently claimed. Schweitzer 
provides no teaching whatsoever on how to index the records, let alone any indication that the 
indexing be achieved with a hashing table and page files contained resident in memory (as 
claimed). A fiuther, and independent, distinction is that Schweitzer provides no teaching or 
suggestion that the records, hashing table and page files should be related by the key module as it 
is defined in the claims. Since these features provide significant performance advantages as 
explained in Applicant's specification, they thus technically and patentably distinguish the 
claimed invention over the prior art as embodied by Schweitzer. 

The Office Action, however, attempts to overcome these deficiencies of Schweitzer by 
relying upon alleged teachings of Coons. In particular, the Office Action acknowledges that 
Schweitzer is silent v^th regard to the use of hashing tables and page files, and the use of key 
modules to relate them. However, the Office Action incorrectly concludes that Coons teaches the 
features of Applicant's claims that are not present in Schweitzer. In particular, the Office Action 
states: 

However, as evidenced by the teachings of Coons, a 
method and system of generating a usage based billing and 
management by collecting and aggregating raw data concerning a 
commimication system usage (title and abstract); and fiuther 
making use of a hash table having therein a key module (a hash 
key) in connection with the usage based records/page files was 
know at the time the invention was made. See Coons Column 7, 
Lines 59-61, Column 5, Lines 13-18, Column 4, Lines 57-65 and 
Column 3, Lines 2-7. Thus, it is respectfiilly submitted that it 
would have been obvioxis to one of ordinary skill in the art at the 
time the invention was made to take the teachings of Coons related 
to the a hash table (hashing) in relation to usage based billing 
records and have modified the teachings of Schweitzer, because a 
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has table is known to increases efficiency when searching for a 
record in a large array of records by directly locating a specific 
session record using an index key (hashed key/"key module") at an 
average time of 0(1), or a constant time. 
As is made clear by the above-quoted portion of the Office Action, Applicant's recitation of "key 
module" throughout the various claims is being equated with a generic "hashed key" or "hash 
key" that would be used, according to the assertions of the Office Action, with the hashing tables 
described by Coons. Applicant's review of the specific portions of Coons' specification that are 
cited by the Office Action, as well as Applicant's careful consideration of the balance of that 
reference, however, has led Applicant to the clear conclusion that even though Coons describes 
the use of hashing tables in conjunction with the management of printer billing records, the 
reference nonetheless fails to describe, teach, or suggest a key module as is presently defined by 
the claims. 

As noted above, both independent claims define a key module as being associated with 
each event data record so as to identify that "usage event data as pertaining to a particular usage 
session." In all embodiments of the claimed invention, these usage event data records are 
converted into a normalized format, and then aggregated. Thus, the kev mod ule as recited in all 
claims is first used to identify the usage event data that it is associated with as pertaining to a 
particular usage session. 

Furthermore, the normalized data records are aggregated in embodiments of the invention 
by associating the normalized records for related events with one another according to the key 
modules. Each of these usage detail record include the unique key module plus usage data of a 
known length for one or more usage event data records pertaining to a same usage session (i.e., 
the usage session identified by the key module in the previous associating step). Thus, these kev 
modules are then used to aggregate event data for particular common event that originate from 
different ones of the plurality of network elements. 

Finally, the aggregating of the records according to the key modules also employs an in- 
memory database comprising a hashing table and page files retained in local memory where the 
page files and hashing table are related according to the kev modules for the records (i.e., the 
same kev modules that are first associated with usage event data to identify that data as 
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pertaining to a particular usage session). 

Coons relates in particular to a system for usage-based billing for printers. Nowhere in 
the Coons reference is there a teaching or suggestion that the system intends to, or otherwise 
finds it desirable to, identify usage event data from different network elements as pertaining to a 
particular usage session and then to aggregate that data for common usage sessions into unified 
usage detail records. This identification and aggregation, as recited in Applicant's claims and 
described in Applicant's specification, is done through the use of the key module. Coons merely 
teaches, at best, collecting different billing records for printers into a central database, and then 
states that the central database may take many alternative forms including that of one or more 
hash tables. Coons does not describe or teach a key module or any equivalent mechanism that is 
associated with event data to tag that data as pertaining to a particular usage session . As it does 
not describe performing such an association, it is therefore axiomatic that Coons also does not 
describe or teach aggregating normalized usage event data records by associating said normalized 
records for related events with one another according to said key modules to form usage detail 
records . Merely concluding, as the Office Action clearly does, that hash tables as described in 
Coons would require a hash key does not entitle the Office Action to also conclude that such a 
hash key would also be used to identify data as pertaining to a particular usage session or to 
aggregate data from the same usage session into usage detail records as is claimed by Applicant. 

Thus, it is clear that Coons does not overcome the deficiencies of Schweitzer or otherwise 
lead one skilled in the art to produce Applicant's invention as presently claimed. 

In this regard, the present claims are allowable over all the prior art made of record in the 
Office Action, and reconsideration is respectfully requested. 
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Conclusion 



In view of the foregoing, the Applicants respectfully request that the Examiner reconsider 
the claims as amended and in light of the above remarks. A timely allowance of all of the 
pending claims is requested. 

Applicants has transmitted this Response concurrently with a transmittal document, 
which document also serves as a Petition for Extension of Time for one (1) month. A check in 
the amount of the extension fee believed due in conjunction with this Response and Amendment 
has been submitted therewith. If the appropriate fee amount has not been identified and 
specifically submitted with this transmittal document, please charge any additional fees or credit 
any overpayments to Deposit Account No. 50-1349. 

Applicant has not herein increased the number of claims beyond the amount for which 
"additional claims fees" have been previously paid. Therefore, no additional fees are believed to 
be due at this time. If there are any other fees due in connection with the filing of this Response, 
please charge any necessary fees to Deposit Account No. 50-1349. 

The Examiner is invited to contact Applicants' undersigned attorneys by telephone to 
discuss any matters if the Examiner feels such discussions may expedite the progress of the 
present application toward allowance. 



Respectfully submitted, 




HOGAN & HARTSON LLP 

555 13'^ Street, N.W. 




Washington, D.C. 20004 
Telephone: 202-637-5600 
Facsimile: 202-637-5910 



Kevin G. Shaw 

Registration No. 43,1 10 



Customer No. 24633 
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